This is not decided, but perhaps, we should ship it for better compatibility with Chrome and the new one is faster and simpler than our traditional normalizer. However, before shipping it, we need to fix a lot of WPT failures, see "white-spaces-after-*":
https://wpt.fyi/results/editing/other?label=master&label=experimental&q=editing%2Fother

Setting tentative scheduled info.

Let's ship it within 139.

https://hg.mozilla.org/mozilla-central/rev/e22987f5c904

We had previously called this out in the Nightly relnotes. Is this something you wanted to mention in the Fx139 relnotes now that it's riding the trains to release?

Release Note Request (optional, but appreciated)
[Why is this notable]: This changes one of the big different behavior between builtin editors of Gecko and the other browsers
[Affects Firefox for Android]: Yes.
[Suggested wording]: The builtin editor for contenteditable and designMode starts handling collapsible white-space(s) before block boundary and white-space sequence between visible contents as similar to Chrome. This means that Gecko stops inserting padding <br> element after white-space before a block boundary like the other browsers.
[Links (documentation, blog post, etc)]: https://groups.google.com/a/mozilla.org/g/dev-platform/c/AApo_nCuR78